Re: 8lgm's SCO "at" hole
der Mouse (mouse@Collatz.McRCIM.McGill.EDU)
Sun, 11 Dec 1994 21:53:28 -0500
>> But agreed, getwd() is currently not a problem. Getcwd is the
>> preferred interface anyway (on modern systems :-)
> The problem is that getcwd() often does a popen("/bin/pwd", ...);
> which isn't safe in a setuid program, so I would consider getwd() to
> be preferable until getcwd() does something sensible.
I entirely agree; indeed, I would say that any setuid program should be
linked with something like
FILE *popen(const char *cmd, ...)
{
write(2,"Unexpected popen call\n",22);
abort();
}
Indeed, one could probably argue that no setuid program should ever use
popen even deliberately, if only because the discipline required to use
fork and exec improves the chances that the code is clean.
> Why can't /bin/pwd be turned into a library routine, or is it simply
> too big?
Isn't that what traditional getwd() is? I can't see why getcwd() ever
did anything but just call getwd(), since presumably whoever implements
getcwd() can know the maximum size getwd() will ever generate.
>> select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout);
> getdtablesize() doesn't exist on all systems and can return very very
> large numbers on systems that have dynamically allocated file tables.
That was (part of) my reaction too...but that's not the real point.
Think about what the first note was talking about: MAXPATHLEN
increasing, so in the future getwd() might construct and (try to)
return a string longer than the statically allocated buffer whose size
was fixed when the application was compiled: essentially, a clash
between compiling now and executing in the future after system changes.
Now go back and look at that select() call again, with that in mind :-)
[And no, I didn't get it either; I had to be told. :-(]
der Mouse
mouse@collatz.mcrcim.mcgill.edu